home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1508 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  7.2 KB
  1. Subject: Re: GEMDOS re-entrancy
  2. Date: Thu, 2 Jun 94 1:05:44 CDT
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <m0q7cvW-0000nrC@sdf.lonestar.org>; from "Evan K. Langlois" at May 28, 94 11:56 pm
  5. Message-Id: <9406012305.AA00242@jelal.north.de>
  6.  
  7. Evan K. Langlois writes:
  8.  
  9. > ========================================================================
  10. >  but this does not mean you cannot sleep for disk IO, like it also
  11. > doesn't mean my editor has to waste CPU time polling the tty for the
  12. > ========================================================================
  13. > 
  14. > Disk IO seems like it may be difficult, but certainly possible.  I don't
  15. > think yor editor should poll for IO at all.
  16.  
  17.  oops :) what i was trying to say is my editor does of course not poll...
  18. and if it works for tty IO then why should it be impossible for DMA disk IO.
  19.  
  20. >  If you have an editor that
  21. > is doing this, throw it away!!   And editor doesn't need to do anything
  22. > but wait for a keypress, so it should use blocking IO, even under normal
  23. > TOS.
  24.  
  25.  (well on vanilla TOS you still need to poll to distinguish ESC
  26. sequences from a single ESC etc. because there is no alarm(), but
  27. anyway...)
  28.  
  29. >  My terminal uses blocking IO by using tfork() to handle input and
  30. > output as separate threads.
  31.  
  32.  btw which one is that?  might interest miff to get cu running... :)
  33. > 
  34. > ========================================================================
  35. >  sure if you don't want to port a real BSDfs, linux ext2 or something
  36. > instead...  i.e. why not make something _better_ than V2? :)
  37. > ========================================================================
  38. > 
  39. > I have the source to HPFS filesystem used by OS/2.  Anyone want it?  It
  40. > doesn't look like it would be TOO difficult to port.  Its kinda half DOS
  41. > with a Minix internal or something.
  42.  
  43.  yes, half-DOS (with some BSD internals)... is that the one that doesn't
  44. even have real file modes?  i would rather take the real thing!
  45.  
  46. >  There are some things that would have
  47. > to be changed though, for example, OS/2 allows you to set the file size when
  48. > you open/create a file - that way the filesystem can allocate exactly enough
  49. > space for it without fragmenting the disk,
  50.  
  51.  well BSDfs mostly takes care of fragmentation problems itself...
  52. hmm :)  anyone would like to read this? (~20K gzip'd...)
  53.  
  54.  
  55.                 A Fast File System for UNIX*
  56.  
  57.  
  58.           Marshall Kirk McKusick, William N. Joy|✓-,
  59.             Samuel J. Leffler|✓=, Robert S. Fabry
  60.  
  61.               Computer Systems Research Group
  62.                  Computer Science Division
  63.  Department of Electrical Engineering and Computer Science
  64.              University of California, Berkeley
  65.                     Berkeley, CA  94720
  66.  
  67.  
  68.                          ABSTRACT
  69.  
  70.           A reimplementation of the UNIX file system is
  71.      described.  The reimplementation provides substan-
  72.      tially higher throughput rates by using more flex-
  73.      ible  allocation policies that allow better local-
  74.      ity of reference and can  be  adapted  to  a  wide
  75.      range of peripheral and processor characteristics.
  76.      The new file system clusters data that is  sequen-
  77.      tially  accessed  and  provides two block sizes to
  78.      allow fast access to large files while not wasting
  79.      large  amounts  of  space  for  small files.  File
  80.      access rates of up to ten times  faster  than  the
  81.      traditional  UNIX  file  system  are  experienced.
  82.      Long  needed  enhancements  to  the   programmers'
  83.      interface  are discussed.  These include a mechan-
  84.      ism to place advisory locks on  files,  extensions
  85.      of the name space across file systems, the ability
  86.      to use long file names, and provisions for  admin-
  87.      istrative control of resource usage.
  88.  
  89.  
  90.      Revised February 18, 1984
  91.  
  92. _________________________
  93. * UNIX is a trademark of Bell Laboratories.
  94. |✓-  William  N.  Joy  is  currently  employed  by:   Sun
  95. Microsystems,  Inc,  2550 Garcia Avenue, Mountain View,
  96. CA 94043
  97. |✓=  Samuel  J.  Leffler  is   currently   employed   by:
  98. Lucasfilm Ltd., PO Box 2009, San Rafael, CA 94912
  99. This work was  done  under  grants  from  the  National
  100. Science  Foundation  under  grant  MCS80-05144, and the
  101. Defense Advance Research Projects  Agency  (DoD)  under
  102. ARPA  Order  No.  4031  monitored  by  Naval Electronic
  103. System Command under Contract No. N00039-82-C-0235.
  104. ...
  105.  
  106. >  and it would really help with
  107. > filesystems like ramfs .. which needs to reallocate RAM constantly.  
  108.  
  109.  and for ramfs, couldn't you just lseek (size) and write something
  110. when this is a problem?
  111.  
  112. > ========================================================================
  113. >  hmm Tgetdate/time is called quite often, MiNT should better keep the
  114. > time itself...
  115. > ========================================================================
  116. > 
  117. > Keep time?  How?  Through the system tick?  Isn't it easier to jst read
  118. > the time from the keyboard clock?  I would think that would be more 
  119. > accurate.  Does this slow down MiNT?
  120.  
  121.  AFAIK GEMDOS uses the etv_timer interrupt itself...  reading the IKBD
  122. clock every time would be slow because it essentially does a blocking
  123. ACIA write and read for a few bytes @ 7800 bps.  is the IKBD's clock
  124. more accurate than the 2.4576 MHz the 200 Hz timer is clocked from?
  125. then maybe synchronize every x minutes...  or leave that to the user
  126. who might have something even more accurate? (DCF77, ntp... :)
  127. > 
  128. > ========================================================================
  129. > >  As for DMA hard disk IO having problems with the BLiTTER,
  130. > > isn't there a semaphore for this?  Yeah, here it is, flock @ 0x0000043E.W
  131. > 
  132. >  is that used for `real' SCSI IO (TT) and IDE too?
  133. > ========================================================================
  134. > 
  135. > The entry for it just says to set that value to non-zero prior to accessing
  136. > the DMA registers to prevent the system or other processes from accessing
  137. > DMA concurrently.
  138.  
  139.  OK for ACSI/FDC, but is this set for the TT's SCSI port for and IDE
  140. disks too?  anyone knows??
  141.  
  142. > ========================================================================
  143. >  ACSI/FDC is a bit on the ST 68881... (i'd have to look it up but i guess
  144. > claus knows these already :)
  145. > ========================================================================
  146. > 
  147. > Nope, thats the FPU and most STs don't have one.  Would be the MFP.
  148.  
  149.  yup 68901, remembered the wrong number...
  150.  
  151. > #5 I think.
  152.  
  153. > ========================================================================
  154. >  not more than ACSI disk if you write a new floppy driver.  except
  155. > that it'll block its channel a bit longer probably, given floppies
  156. > access time and data rate... :)
  157. > ========================================================================
  158. > 
  159. > Hmm .. lessee that's 11K/second.  So, we might be able to pass the 
  160. > test the Intel users thought up?   The way they test for REAL multitasking
  161. > is being able to format a floppy in the background :-)
  162. > 
  163.  hmm actually i've done that already, answered some mail on ttyv2 while
  164. pumpup.prg was running on console... :)  its just there are not many
  165. cycles left now with all the blocking/polling going on.
  166.  
  167.  cheers
  168.     Juergen
  169. -- 
  170. J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
  171.                                 ...ohne Gewehr
  172. PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA 
  173.